making them impossible to be handled safely in user code.

They can't be handled safely regardless, I think, but at least we can have useful setters.

@Ralith wrong wording, I think I meant UB. There are likely more safety constraints on &mut c_void (that a cast/transmute can never uphold) than there are for passing an opaque *mut c_void around?

I think it's actually okay to synthesize references to ZSTs? But the lifetime isn't doing any good here.

Makes sense. What is your verdict on SECURITY_ATTRIBUTES, before we merge this?

That's a tricky case, since unlike a windowing handle it seems like it theoretically could address a value on the stack and readily benefit from lifetime checking. So long as we're defining it ourselves/as c_void, that's difficult but not strictly impossible for a user to take advantage of--typically going through pointer casts will erase lifetime information, but you can put it back if you really want. Do we know where they come from, and in what form?

It's just a POD but with a pointer to a "security descriptor". Looks like the caller is expected to create it as follows:

https://learn.microsoft.com/en-us/windows/win32/secauthz/creating-a-security-descriptor-for-a-new-object-in-c--

Either way it's allowed to be NULL but that should be representable by leaving the raw/FFI pointer field at null_mut() even though our builder has no way to "unassign" it.

API-wise, I wonder if what we're doing here is a semver break since the target type remains the same, and the original &'a mut coerces into *mut.